-
Notifications
You must be signed in to change notification settings - Fork 6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improvement(rpc-server): Add additional logs for shadow_data_consistency
#93
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd like you to add docstrings to the functions you introduce for readability. This is a general request from me.
Also, could you please consider the changes I've proposed? The change would also affect other places, so I'm not commenting on those.
I can't entirely agree with the place for the log message for data consistency. However, I don't have any better suggestions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have you covered the thing that we should give different logs:
- when both answers are successful, but they do not match
- when one or both answers were not able to be collected properly
?
I haven't forgotten. I analyzed the situation and found a case when an error is normal. For example, if the block does not exist then both services return an error and we need to compare these errors and make sure that we return the same error as near_rpc. At the moment I just added the compared objects to the logging, I hope this will improve the situation with the investigation of mismatching. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My requests and concerns were addressed. I am approving, though I wouldn't merge until @telezhnaya approves.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry, but this does not address the thing I've asked for. The initial idea was to simplify the logs and help to identify the cases when both services give successful results, and these results do not match. You haven't covered this.
You are right! I lost some moments and I will improve code coming soon. Sorry for that! |
5a25ede
to
3a258b9
Compare
d332da5
to
ba203e6
Compare
shadow_data_consistency
shadow_data_consistency
shadow_data_consistency
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for the detailed PR description. I'm leaving some changes request, but I still need to review the PR.
I am thinking about the way ResponseState
works. I feel it should be improved, but I can't concentrate right now to tell how.
b37ec6f
to
8dc190a
Compare
shadow_data_consistency
shadow_data_consistency
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I see no more major issues here.
But, this does not fix #92, please check it's not closed automatically after the merge
Thank you
rpc-server/src/utils.rs
Outdated
// Both services(read_rpc and near_rpc) have a successful response | ||
// if data mismatch we are logging into `shadow_data_consistency_successful_responses` | ||
// both response objects for future investigation. | ||
tracing::warn!(target: "shadow_data_consistency_successful_responses", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Introduction of couple of new targets really bothers me. Can you reuse the shadow_data_consistency
we already have and instead define the cause of the warning in the log message itself, please?
let read_rpc_response_json = match &result { | ||
Ok(res) => serde_json::to_value(res), | ||
Err(err) => serde_json::to_value(err), | ||
let (read_rpc_response_json, response_success) = match &result { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't feel response_success
is a good name for this variable. Maybe something like is_response_ok
(is_
could help identify it's a bool
, _ok
is closer to what we deal with). What do you guys think @kobayurii @telezhnaya ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
100% agree
2. Logs inmprovements for shadow_data_consistency. Add Full objects in log if data mismatch
rpc-server/src/utils.rs
Outdated
) | ||
}; | ||
return Err(ShadowDataConsistencyError::ResultsDontMatch(format!( | ||
"{err}. Reason: {reason}. Description {description}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you post an example of such input for clarity, please?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes! Sure.
exampl.log
@kobayurii @telezhnaya
This is pretty similar to what @kobayurii did in this PR for separating logs. What do you think? I guess we should merge this PR and open a separate followup issue to cover the idea described. |
#92
In this pr we improve shadow_data_consistency logs.
Data may mismatch in 4 cases:
if data mismatch we are logging into
shadow_data_consistency_successful_responses
both response objects for future investigation.we are logging into
shadow_data_consistency_read_rpc_failure_response
just message about mismatch data without objects. In the future we should be investigate why we got error in the read_rpc.we are logging into
shadow_data_consistency_near_failure_response
just message about mismatch data without objects. Expected that all error will be related with network issues.we are logging into
shadow_data_consistency_failure_responses
both response objects for future investigation.Expected we will only have a difference in the error text.